home *** CD-ROM | disk | FTP | other *** search
/ Internet Tools (InfoMagic) / Internet Tools.iso / dos_win / winsock / FAQ < prev    next >
Text File  |  1994-09-05  |  16KB  |  379 lines
  1.            Frequently Asked Questions About
  2.              Windows Sockets Version 1.1
  3.                   6 Sep 1994
  4.  
  5.   This FAQ has been put together by Mark Towfiq, with much-appreciated
  6. assistance from Jay Allard, Bruce Backman, Paul Brooks, Mark Fisher,
  7. Martin Hall, Simon Hewison, Mike Morse, Bob Quinn, Ed Schwalenberg,
  8. J. Daniel Smith, Bill Tang, Dave Treadwell, and Fred Whiteside.  If
  9. you have any modifications to this FAQ, send them to
  10. towfiq@East.Sun.Com, and I will fold them into the next revision.
  11.  
  12.   First of all, the questions:
  13.  
  14. 1.    What is Windows Sockets?
  15. 2.    What is the latest version?
  16. 3.    When is the next rev of the specification?  Why not sooner?
  17. 4.    Where can I get a/the WINSOCK.DLL?
  18. 5.    Why isn't there just one WINSOCK.DLL?  Do I need a TCP/IP already to
  19.       use it?
  20. 6.    Where can I contact Windows Sockets application and implementation
  21.       vendors?  (include list of address, phone contacts)
  22. 7.    Where can I get sample apps and tests?
  23. 8.    Will Windows Sockets be in _____?
  24. 8.1.  Will Windows Sockets be in Windows NT?
  25. 8.2.  Will Windows Sockets be in Windows for Workgroups?
  26. 8.3.  Will Windows Sockets be in DOS?
  27. 8.4.  Will Windows Sockets be in Unix?
  28. 8.5.  Will Windows Sockets be in Win32s?
  29. 9.    What about standard APIs for ____?
  30. 9.1.  What about standard APIs for FTP?
  31. 9.2.  What about standard APIs for Telnet?
  32. 9.3.  What about standard APIs for SNMP?
  33. 9.4.  What about standard APIs for RPC?
  34. 9.5.  What about standard APIs for TLI/XTI?
  35. 10.   Does Windows Sockets work over protocols other than TCP/IP?
  36. 11.   Why no SOCK_RAW?
  37. 12.   Why isn't it possible to share sockets between tasks?
  38. 13.1. How do I get my IP address?
  39. 13.2. Why no SIOCGIFADDR?
  40. 14.   When should I use blocking vs. nonblocking sockets?
  41. 15.   What about other socket options that BSD supports?  Ioctls?
  42. 16.   How can I get the local username?
  43. 17.   Do I need to initialize the WSAData structure before calling
  44.       WSAStartup?
  45. 18.   If I write a Windows Sockets program for DOS, will I be able to
  46.       communicate with a Sockets program on UNIX?
  47. 19.   Is it possible to create sockets that map to a dll rather than an
  48.       application?  I have tried a WSAStartup() as part of my LibMain, but
  49.       the sockets that are created are owned by the application, not by the
  50.       DLL. It would be desirable for me to have some of the sockets that
  51.       are opened have "A Global (DLL wide) Scope".
  52. 20.   A *Class* of questions that could be answered are related to porting
  53.       extant BSD applications to Windows Sockets: "How to I implement the
  54.       xxxx function call in my Windows Sockets application?" (e.g. fcntl(),
  55.       readv(), etc).
  56. 21.   Is there a Pascal/Visual Basic/Visual Cobol header file for Windows
  57.       Sockets?
  58. ----------------------------------------------------------------------
  59. 1.  What is Windows Sockets?
  60.  
  61. Answer: The Windows Sockets specification defines a network programming
  62. interface for Microsoft Windows which is based on the "socket" paradigm
  63. popularized in the Berkeley Software Distribution (BSD) from the University
  64. of California at Berkeley.  It encompasses both familiar Berkeley socket
  65. style routines and a set of Windows-specific extensions designed to allow
  66. the programmer to take advantage of the message-driven nature of Windows.
  67.  
  68. The Windows Sockets Specification is intended to provide a single API to
  69. which application developers can program and multiple network software
  70. vendors can conform.  Furthermore, in the context of a particular version
  71. of Microsoft Windows, it defines a binary interface (ABI) such that an
  72. application written to the Windows Sockets API can work with a conformant
  73. protocol implementation from any network software vendor.  This
  74. specification thus defines the library calls and associated semantics to
  75. which an application developer can program and which a network software
  76. vendor can implement.
  77.  
  78. Network software which conforms to this Windows Sockets specification will
  79. be considered "Windows Sockets Compliant".  Suppliers of interfaces which
  80. are "Windows Sockets Compliant" shall be referred to as "Windows Sockets
  81. Suppliers".  To be Windows Sockets Compliant, a vendor must implement 100%
  82. of this Windows Sockets specification.
  83.  
  84. Applications which are capable of operating with any "Windows Sockets
  85. Compliant" protocol implementation will be considered as having a "Windows
  86. Sockets Interface" and will be referred to as "Windows Sockets
  87. Applications".
  88.  
  89. 2.  What is the latest version?
  90.  
  91. Answer: The latest version of the specification is 1.1.
  92.  
  93. 3.  When is the next rev of the specification?
  94.  
  95. Answer: The next rev. (2.0) is actively being worked on.  You may want
  96. to subscribe to any of the Windows Sockets 2.0 mailing lists:
  97.  
  98.     From: Dave B. Andersen, Intel Architecture Labs
  99.     Subject: Winsock 2 mailing lists
  100.  
  101.     For those of you that have not otherwise been notified,
  102.     a set of mailing lists have been set up for Winsock 2 
  103.     discussions.  These are located on mailbag.intel.com.
  104.  
  105.     To get a list of the mailing list names and to learn how
  106.     to subscribe, send email to majordomo@mailbag.intel.com.  
  107.     Leave the subject blank, and include the following
  108.     commands on separate lines in the body:
  109.         lists
  110.         help
  111.  
  112.     The majordomo program will respond with email that provides
  113.     the requested information.
  114.  
  115.     I would encourage all of you to subscribe to the list(s) of
  116.     your choice so that we can continue in earnest the work of
  117.     defining Winsock version 2.
  118.  
  119. 4.  Where can I get a/the WINSOCK.DLL?
  120.  
  121. Answer: You can most probably get one from the same place you got your
  122. TCP/IP software from.
  123.  
  124. 5.  Why isn't there just one WINSOCK.DLL?  Do I need a TCP/IP already
  125.     to use it?
  126.  
  127. Answer: The Windows Sockets specification defines the top level of the DLL,
  128. the part which is called by user programs.  The method a given WINSOCK.DLL
  129. will use to access TCP/IP (or NetWare, or AppleTalk, or DECNet ...) depends
  130. on the networking package you have installed, and therefore must vary.  A
  131. WINSOCK.DLL is therefore just an interface to whatever existing protocol
  132. you already have installed.  An illustration would help:
  133.  
  134.        +---------------------------------+
  135.        |  WinSock compliant application  |
  136.        +---------------------------------+
  137.        +---------------------------------+ <--- WinSock API
  138.        |       Windows Sockets DLL       |
  139.        +---------------------------------+
  140.        +---------------------------------+ <--- Protocol Stack API
  141.        |   Protocol Stack (e.g. TCP/IP)  | (typically proprietary)
  142.        +---------------------------------+
  143.        +---------------------------------+ <--- Hardware Driver API
  144.        |        Hardware Driver          |   (Packet Driver, NDIS, ODI,
  145.        +---------------------------------+    or proprietary)
  146.        +---------------------------------+ <--- Hardware Interface
  147.        |   Network (hardware) Interface  |    (hardware specific)
  148.        +---------------------------------+
  149.                        |
  150.                        +----> network
  151.  
  152. 6.  Where can I contact Windows Sockets application and implementation
  153. vendors?  (include list of address, phone contacts)
  154.  
  155. Answer:
  156.  
  157.     Date: Tue, 6 Apr 93 12:53:37 PDT
  158.     From: tang@documentum.com (Bill Tang)
  159.     To: winsock@Microdyne.COM
  160.     Subject: vendor list (long)
  161.  
  162.     Thanks to all that responded to my previous inquiry of vendor
  163.     implementations. I am posting a summary and will keep the list updated
  164.     if I receive more information.
  165.     -------------------------------------------------------------------------
  166.     SUMMARY
  167.     -------------------------------------------------------------------------
  168.     Company            Shipping?   Notes
  169.     -------------------------------------------------------------------------
  170.     3Com Corp            Yes
  171.     Beame & Whiteside        Yes
  172.     Bristol Technology        Yes        Unix Winsock part of Wind/U product.  
  173.                         (203) 438-6969 or info@bristol.com 
  174.     Distinct Corp        Yes    
  175.     FTP Software        Yes        DLL available from
  176.                         vax.ftp.com:/pub/winsockapi
  177.     Frontier Tech        Yes
  178.     IBM                Yes
  179.     JSB Corporation        Yes
  180.     Lan Design            Yes
  181.     Lanera Corp            Yes
  182.     Microdyne            Yes
  183.     Microsoft(W NT 32b)        Yes
  184.     Microsoft(W NT 16b)        Yes
  185.     Microsoft(W 3.x 16b)    ???
  186.     NetManage            Yes
  187.     Network Research        ???
  188.     Novell            Yes        DLL available from
  189.                         ftp.novell.com:
  190.                         /pub/lanworkplace/lwp4dos/WinSock
  191.     Persoft            Yes        Contact Rhonda Harris at
  192.                         harrisr@pervax.persoft.com
  193.                         or (608) 273-6000.
  194.     Spry            Yes
  195.     SunSelect            Yes
  196.     Ungermann Bass        Yes
  197.     Walker Richer Quinn        Yes
  198.     Wollongong            Yes
  199.  
  200. 7.  Where can I get sample applications and tests?
  201.  
  202. Answer: Files and information related to the Windows Sockets API are
  203. available via FTP (user: "anonymous", password: your e-mail address)
  204. on the host SunSite.UNC.EDU, in /pub/micro/pc-stuff/ms-windows/winsock.
  205. Note: if you do not have FTP access to the Internet, send a message
  206. with the word "help" in the body to either ftpmail@SunSite.UNC.Edu, or
  207. ftpmail@DECWRL.DEC.Com (in the UK mail to ftpmail@doc.ic.ac.uk), to
  208. obtain information about the FTP to Mail service there.
  209.  
  210. 8.  Will Windows Sockets be in _____?
  211.  
  212. 8.1.  Will Windows Sockets be in Windows NT?
  213.  
  214. Answer: Yes.  In 16 and 32-bit versions.
  215.  
  216. 8.2.  Will Windows Sockets be in Windows for Workgroups?
  217.  
  218. Answer: Yes.
  219.  
  220. 8.3.  Will Windows Sockets be in DOS?
  221.  
  222. Answer: Paul Brooks of TurboSoft (paul@abccomp.oz.au) tells me:
  223.  
  224.     As for a Windows Sockets for DOS - we have a library that is
  225.     pretty much complete. The goal was to produce a DOS library and
  226.     Binary API which would allow developers to code applications using
  227.     the Windows Sockets 1.1 spec. and have it run exactly the same
  228.     under DOS as Windows - blocking and non-blocking modes,
  229.     Asynchronous calls, the works. Apart from some AsyncGetXXXbyYYY
  230.     calls the rest works, although it is not possible to capture all
  231.     the Windows-specific semantics of some areas.
  232.  
  233. I am sure you can contact him for more information.  JSB also has a
  234. standardized Berkeley Sockets API for DOS which provides access to all
  235. TCP/IP implementations.
  236.  
  237. 8.4.  Will Windows Sockets be in UNIX?
  238.  
  239. Answer: Because the syntax and semantics of the Winsock specification
  240. differ enough from standard BSD sockets, UNIX Winsock implementations
  241. are now appearing.
  242.  
  243. 8.5.  Will Windows Sockets be in Win32-S?
  244.  
  245. Answer: Yes, Win32s 1.1 contains a thunking layer that converts 32-bit
  246. Windows Sockets calls to 16-bit Windows Sockets.  It should work on
  247. top of any 16-bit WINSOCK.DLL.
  248.  
  249. 9.  What about standard APIs for ____?
  250.  
  251. 9.1.  What about standard APIs for FTP?
  252.  
  253. Answer: Not yet.
  254.  
  255. 9.2 What about standard APIs for Telnet?
  256.  
  257. Answer: Not yet.
  258.  
  259. 9.3 What about standard APIs for SNMP?
  260.  
  261. Answer: In the works.  Send e-mail to listserv@SunSite.UNC.EDU with
  262. "subscribe winsnmp" in the body of the message to join the list.
  263.  
  264. 9.4 What about standard APIs for RPC?
  265.  
  266. Answer: Microsoft will be providing an implementation of DCE RPC.  Also in
  267. the works is the definition of a standard implementation of ONC RPC (known
  268. as RPC for Windows) which will be made available by multiple vendors.  To
  269. contribute to the discussion, send email to rpc4win@wco.ftp.com.
  270.  
  271. 9.5 What about standard APIs for TLI/XTI?
  272.  
  273. Answer: No, not yet.  Vendors chose to do Windows Sockets because of the
  274. sockets application and knowledge base, however anyone out there is free to
  275. try a Windows TLI/XTI Specification.
  276.  
  277. 10.  Does Windows Sockets work over protocols other than TCP/IP?
  278.  
  279. Answer: Yes, it does.  For example, DEC PathWorks v5.0 supplies both
  280. TCP/IP and DECNet via WinSock, and Windows NT includes mechanisms for
  281. multiple protocol support in Windows Sockets, both 32-bit and 16-bit.
  282.  
  283. 11.  Why no SOCK_RAW?
  284.  
  285. Answer: SOCK_RAW is optionally implemented by many major Windows Sockets
  286. vendors.  It is not mandated now because: 1) not every stack vendor can
  287. supply a complete SOCK_RAW interface, and 2) we did not have time to define
  288. the minimal subset every vendor could provide (e.g. maybe just ICMP).
  289.  
  290. 12.  Why isn't it possible to share sockets between tasks?
  291.  
  292. Answer: The real answer is that it wasn't considered sufficiently important
  293. for 1.1, but is high on the list for inclusion in 2.0.
  294.  
  295. 13.1.  How do I get my IP address?
  296.  
  297. Answer: Do a gethostbyname() on the output from gethostname().
  298.  
  299. 13.2.  Why no SIOCGIFADDR?
  300.  
  301. Answer: It was not included because there were concerns it could not be
  302. supported across platforms.  It may be included in version 2.0 of the spec.
  303.  
  304. 14.  When should I use blocking vs. non-blocking sockets?
  305.  
  306. Answer: Try to use non-blocking sockets whenever possible; certainly if you
  307. are coding a Windows application from scratch.  Blocking sockets should
  308. only be used when trying to maintain portability between UNIX/MS-DOS and
  309. Windows.
  310.  
  311. 15.  What about other socket options that BSD supports?  Ioctls?
  312.  
  313. Answer: Some vendors may support them.  Do not rely on ones not explicitly
  314. mentioned in the specification, however.
  315.  
  316. 16.  How can I get the local username?
  317.  
  318. Answer: Based on a suggestion from Simon Hewison
  319. (p0063886@cs3.oxford-brookes.ac.uk), one idea is to call WNetGetUser()
  320. in the NETWORK.DRV.  If a vendor has supplied a NETWORK.DRV then this
  321. will work, if not you can just use some other method.  Thus you could
  322. write a bit of code thus:
  323.  
  324.     WNetGetUser(szNetUserId,sizeof(szNetUserId);
  325.     if (strlen(szNetUserId)==0) {
  326.         /* call some other method of getting
  327.            userid, eg. the lan manager call NetWkstaGetInfo */
  328.     }
  329.  
  330.   Information on this API call is in the Windows Device Driver Adaption
  331. Guide.
  332.  
  333. 17.  Do I need to initialize the WSAData structure before calling
  334. WSAStartup?
  335.  
  336. Answer: No, WSAStartup does not retrieve the contents of the WSAData
  337. structure pointed to, it fills it in.
  338.  
  339. 18.  If I write a Windows Sockets program, will I be able to communicate
  340. with a Sockets program on UNIX or any other non Windows platform?
  341.  
  342. Answer: Absolutely!  This common question is the result of confusing
  343. protocols with the APIs; communicating programs need not have been
  344. created with the same APIs, as long as they are using the same
  345. (transport & network) protocols.
  346.  
  347. 19.  Is it possible to create sockets that map to a dll rather than an
  348. application?  I have tried a WSAStartup() as part of my LibMain, but the
  349. sockets that are created are owned by the application, not by the DLL. It
  350. would be desirable for me to have some of the sockets that are opened have
  351. "A Global (DLL wide) Scope".
  352.  
  353. Answer: The way this situation has been dealt with by developers is to have
  354. your DLL create a "helper process" which will perform all Windows Sockets
  355. operations on behalf of your applications (thereby having all sockets owned
  356. by the helper process' task).
  357.  
  358. 20.  A *Class* of questions that could be answered are related to porting
  359. extant BSD applications to Windows Sockets: "How to I implement the xxxx
  360. function call in my Windows Sockets application?" (e.g. fcntl(), readv(),
  361. etc).
  362.  
  363. Answer: In general, you will have to code such functions yourself, although
  364. it would not hurt to suggest them for the next revision of the
  365. specification as well.
  366.  
  367. 21.  Is there a Pascal/Visual Basic/Visual Cobol header file for Windows
  368. Sockets?
  369.  
  370. Answer: The Pascal and Visual Basic forms are already in the FTP
  371. archive.  Look there for any other header files that people may have
  372. developed so far.  It should be pointed out that not all the Winsock
  373. functions can be called from Visual Basic and the subset that can be
  374. called are not really enough for a true app (for example, you can't
  375. call gethostbyname()).  To use Winsock from VB requires a translation
  376. DLL that will probably have to be written in C.  To date, there is no
  377. public domain implementation, although several vendors have announced
  378. toolkits for Winsock for VB.
  379.